1. Field of the Invention
This invention relates to network traffic transport, and more specifically to managing and transport of traffic from a source node or subnet over a network to a destination node or subnet.
2. Background Information
The rapid growth of the Internet and new digital services is driving Internet service providers to provide huge bandwidth. The explosive growth of the Internet as well as the proliferation of virtual private networks (VPNs) has resulted in the amount of data traffic worldwide surpassing voice traffic. It is expected that the amount of data traffic will continue to outpace voice traffic for years to come. At the same time, there is strong demand from end users to keep the cost of networking down. These two factors result in a need for network architectures that enable service providers to deliver huge volumes of traffic in a cost effective manner. Internet protocol (IP) over wavelength division multiplexing (WDM) network architecture has proved to be possibly the most cost effective architecture.
Innovations of dense wavelength division multiplexing (DWDM) technology present attractive opportunities to evolve DWDM technology toward an optical networking infrastructure with transport, multiplexing, switching, routing, survivability, bandwidth provisioning, and performance monitoring, possibly supported at the optical layer. The development of fast router technologies has enabled the aggregation of slower data stream traffic into streams suitable for DWDM.
In some IP network structures, IP subnets are interconnected by another network. In a typical IP over WDM network structure, IP subnetworks are interconnected by an intermediate network composed of a switched optical core. Routers in IP subnets which are directly connected with the intermediate network are called border routers. In the case of an optical core, the border routers are directly connected with the optical core network via an optical cross connect (OXC). The border routers are high speed and capable of statistically multiplexing data streams to the capacity that an OXC supports. A border router can generate and terminate the traffic from an optical label switched path (OLSP), i.e., one lightpath. It may not be desirable or necessary for the non-border router to maintain routing information inside the intermediate network, e.g., optical core. The non-border routers in the IP domain may send the LSP setup request to the border routers. Generally, an established lightpath is needed to carry LSPs across the optical core from a source border router to a destination border router.
In determining a path to route traffic from an IP subnet border router through another network to a destination in another IP subnet, two routing issues exist. First, how is a path allocated through the intermediate network, and secondly what routing tasks occur in the routers at the IP subnets. In current networks, the lightpaths are set up to carry the LSPs by the border routers. The LSPs between the same source and destination border router are aggregated onto a directed lightpath or existing lightpaths that provide IP connectivity between these two border routers. However, this method can only accomplish a limited network resource optimization. A network reconfiguration may be applied to optimize the resource utilization, however, such a reconfiguration is inherently static and can only be conducted in a large time scale because the frequent lightpath setup and tear down due to a frequent reconfiguration will result in an undesirable thrash effect for customer traffic and degraded network performance.
FIG. 1a shows a topology diagram of lightpaths in an optical core. Router 22 in network 10 is connected to border router 15. A path <R2, R3> is established via optical cross connects 20 that exist throughout optical core network 12. Non-border router 22 then initiates a request for a path from border router 15 (R1) through network 12 to border router 16. A new path <R1, R3> is established from border router 15 to border router 16 through network 12.
FIG. 1b shows another topology diagram of lightpaths in an optical core. Here, there is an existing path <R1, R2>. Border router 15 initiates a request for a path <R1, R3>. The directed lightpath <R1, R3> is established from border router 15 to border router 16. As can be seen in FIGS. 1a and 1b, these two paths have not shared any resource in network 12.
This current method presents several other problems such as: increases the number of connections across the center of the optical network thereby increasing wavelength resources used; increases the blocking probability of a lightpath setup across the center of the optical core; presents unbalanced load distribution problems; and increases setup delay since new lightpaths are established for each request.
FIG. 2 shows a topology diagram of management of lightpaths through a network to different destinations. Lightpaths between routers are shown as dotted lines. Label switched router (LSR) 70 (border router) at IP subnet 60 has an established path for traffic from IP subnet 60 through network 62 to LSR 78 at IP subnet 66. LSR 70 further has an established path from IP subnet 60 through network 62 to LSR 76 at IP subnet 64. LSR 72 at IP subnet 60 has established paths from IP subnet 60 through network 62 to LSR 78 at IP subnet 66 and from IP subnet 60 through network 62 to LSR 76 at IP subnet 64. Paths from LSR 70 and LSR 72 may enter network 62 at optical cross connect 74 before traveling through other optical cross connects in network 62 to their destination subnets. This is inefficient management of routing considering that there are two separate paths carrying traffic between the same source and destination subnets, i.e., two paths between IP subnets 60 and 66, and two paths between IP subnets 60 and 64.
Currently, three approaches have been used regarding management of routing in the outer IP subnets. In the first approach (multihop), traffic aggregation is done inside the optical core network 62. The traffic may pass several intermediate nodes that process the traffic electronically. This causes a glass ceiling effect because of the limits of electronic processing, e.g., IP or Asynchronous Transfer Mode (ATM) buffering/classification/scheduling. This approach increases equipment costs, plant space requirements, and cannot keep pace with full, multi-wavelength line rates. The virtual topology design, such as how connections among the optical nodes are determined, becomes very critical to providing good performance.
A second approach, also known as an overlay model or client server model, provides a separation of IP and optical domains. IP routers are the client, and the optical network is the server. Conceptually, this model is similar to “circuit-layer” interworkings, e.g., IP-over-ATM incarnations such as MultiProtocol Over Asynchronous Transfer Mode (MPOA). In this model, scalability is a critical factor and requires θ(n3) control message flooding and θ(n2) client connections, where θ represents the magnitude order and n represents the number of border routers. The IP routers submit connection requests to an optical controller and the optical controller allocates the lightpaths to those requests.
In a third approach, known as a peer model, an optical cross connect is treated as a network element, e.g., a label switched router (LSR). General Multiprotocol Label/Lambada switching (GMPLS) is used to support this network model. Lightpaths are requested by LSRs. In order to support full mesh connectivities, e.g., there is at least one direct virtual link (lightpath) between LSRs. The number of connections will be θ(n2) where n is the number of LSRs in the network.
All three approaches have inherent problems. Therefore, there is a need for methods and systems for efficient management and transport of traffic over a network that avoids the problems of current systems.